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Description 

BACKGROUND OF THE INVENTION 
1 . Field of the Invention 

r0001l The present invention relates to a content dis- 
ribution apparatus, a content receiving apparatus and 
a content distribution method. More particularly, it re- 
lates to technology in real-time distribution o f content 
via an open network such as the Internet whereby p o- 
Lion is provided against content theft by third parties 
and unauthorized copying of content by a content recip- 
ient thereby enabling transmission and reception of 
content data while considering copyright protection. 



2. Description of the Related Art 

[0002] in recent years, the digitization of the home 
sound and image (audio/visual; 
AV) environment, as exemplified by the start of d gital 
broadcasts and the sales of digital AV equipment has 
gained much attention. Digital AV data enables diverse 
?y P es of compression, is amenable to processing as 
multimedia data, tolerates unlimited playback without 
deterioration, and has other features which are expect- 
ed to result in an expansion in its applicat.on in the fu- 

mooa] On the other hand, digital AV data technology 
s accompanied by the problem of easy "nauthonzed 
copying of content. More specifically, any type of digital 
content can in principle be used to create a copy iden- 
ica! to the original and indefinitely durable by means o, 
bit copying, in the process of unauthorized content cop- 

Ko4] A variety of technologies are being studied for 
he purpose of preventing unauthorized copying. One of 
these is the 1394CP Content Protection System Spec- 
fication being studied by the CPTWG (Content Protec 

thentication procedure is performed baforeh^ I be- 
tween sending and receiving nodes for content (such as 
MPEG data) to be transferred between nodes connect- 
ed by the IEEE 1394 bus, to enable shared use of an 
encryption key (content key). Thereafter, this encryption 
key te used to encrypt the content and then encrypted 
content is transferred, and it is not possible for nodes 
Z TL the nodes that performed the authent.cat.on 
procedure to decrypt the content. By ^^"J" 
a node other than the authenticated nodes (friat is, a 
third party node) does not know the encryption key, even 
he node were able to capture the transferred data that 
t e encrypted content data), ft would not be able to 
decrypt it. Nodes that can participate in this authentica- 
tion procedure are limited to nodes that receive permis- 
sion to do so by an authentication organ.zat.on before- 
hand, thereby preventing an unauthorized node from 
obtaining the encryption key, and thus prevent.ng unau- 



thorized copying of content. ■ 
00051 The distribution of digital content is not, of 
55. limited to transfer via the IEEE 1 394 bus^and 
general networks are expected to be used. The Intern t 
5 I a strong candidate for building a technology ^infra- 
structure that is not wedded to public networks or phys- 
ical/link networks. 

[0006] in conventional content distribution as prac 
iced however, digital content on the Internet (and .n 
„ paScular digital AV streams ) was mainly transfer j , 
Ss raw form by the RTP (Real-time Transport Protocol) 
without copyright protection provided by prevention of 
third-party theft and unauthorized copying by a recipi- 
ent. 

SUMMARY OF THE INVENTION 

[0007] Accordingly, it is an object of the present invers- 
ion in consideration of the above-noted situation, to 
» providecontentdistribulionapparalus,acontentreceiv h 

ing apparatus, and a content distributor, method, wh ch 
provide protection from copying when d.gital content is 
transferred on the Internet by real-time streaming 
[0008] A feature of the present .nvent.on is that mfor 
2 s mation with regard to encryption and oncodhg^ro- 
quired to provide copy protection for d.gital I content ,s 
efficiently appended as various headers to the content, 
making use of the characteristics of the Internet. 
0009] One aspect of the present invention prides 
30 a content information distribution apparatus for d.str.b- 
uting encrypted content information, via a network in ac- 
cordance with a prescribed transport protocol, to otter 
end apparatus in a communication authent.cated by an 
authentication process including at least one procedure 
35 ofanauthenticationprocedureandakeyexchangepo- 
cedure, comprising: (a) a unit for encrypting content in- 
formation encoded by a prescribed encoding system 
b) a unit for generating an encryption attnbute header 
ncludingattribute information with regard to the encryp- 
40 tion of the content information; (c) a unit °r pe»g 
transport protocol processing requ.red to transfer the 
content information and for generating a ba» transport 
header to be added to the content information , to wb ch 
the encryption attribute header has been added, and (d) 
45 a unit foisending to the other end apparatus that ,s au- 
thenticated a packet including the basic transport head- 
ache encryption attribute header, and the encrypted 
content information, wherein the encryption atlnbute 
header is set into an expansion transport header -**m 
50 a packet header of the packet or into a pay toad header 
within a payload to be encrypted of the packet. 
Too 0] « is preferable that the encryption attnbute 
header includes at least one of the existence or non- 
existence of encryption of the content .nformation and 
55 the encryption system of the content informat.on _ 
[0011] It is preferable that the encryption attnbute 
neader includes a copy attribute field hav.ng a plurahty 
of bits with regard to the number of copying of the con- 
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tent information. 

[0012] It is preferable that the encryption attribute 
header includes a counter field indicating a change in 

an encryption key. 

[0013] It is preferable.that the unit (b) sets the encod- 
ing information, which indicates the encoding system for 
the content information into the expansion transport 
header or into the payload header. . . 

[0014] " It is preferable that the unit (c) further codes 
into the basic transport header at least information to 
the effect that there. is a possibility that the content in- 
formation is encrypted, and wherein the unit (b) codes 
into the expansion header at J east information as to 
, whether or not the content-information to be transferred 
is encrypted. 

;> [0015] It is preferable that the unit (bj '.codes into the 
. expansion header information as to whether or not the 
content information to.be transferred, is encrypted. 
[001 6] The above-noted content information distribu- 
tion apparatus can Jurlher comprising: (e) a unit for .'gen- 
.. ^ erating a content attribute header that includes content 
-attribute; information ['with, regard to content information, 
-/and for setting -this, content ."attribute header into the ex- 
pansion transport iheader or into, the payload header. 
[0017] . The'content attribute,. header need npt.be en-. 
; ,'crypfed. V*; ( ;^ *" [\[ !'V : I* 
rr [0018], The .unit, (a) generates the' encryption; key 
based on an identifier, that uniquely identifies a storage 
( medium sent .from the other end apparatus .in the com- 
^'^municatiqh.;-^'./^.'.*'!* .^ r ; .\ \ : V" ' 

..; [0019] , . Another, aspect of the present Invention pro- 
vfdes.a content information receiving apparatus authen- 
'[ ticated by ah authentication , process including at least 
* one procedure^of an authentication procedure and a key 
, ( , exchange procedure.and which receives encrypted con- 
' tent information "via a network in accordance .with apre- 
" scribed transport protocol, comprising: (aaj a,unit for re- 
, .....ceiyingfrom a sending apparatus^ packet containing a 
, u basic.trahsp6rt header, an encryption attribute. header 
\' s/ , jncludingattri^ 

tioh of the content information, and encrypted content 
information; (bb) a unit for referring to the basic transport 
header or, .encryption attribute -header, and judging 
whether or not the content information is encrypted or 
„ whether.there is a possibiirtyihatihe content information 
is .encrypted; ..and ,(ccj a .unit that, when a judgment is 
\ .made .by "the unit '(bb) that the content information Js en- 
, crypted, , decrypts the encrypted : content t information, 
. . based on the attribute information with regard to encryp- 
tion included in .the encryption attribute header. .. - - 
[0020] It is preferable that .the unit ."(bb),- when there is 
a possibility that the content" information, is encrypted, 
.. . refers to the .encryption attribute header and judges 
>r whether . of not the content information is -encrypted. 
. JQ021] '.It is preferable that the unit (bb) refers to the 
basic transport header or to the encryption attribute 
. . header.to make a judgment as to the encoding system 
. of . the content information. .', .. _ ,. „ . ,. 



[0022] The above-noted apparatus can further com- 
prising: (dd) a unit for referring to a received basic trans- 
port header and, when a prescribed delay time has 
,. elapsed or a prescribed number of packets have been 
5 discarded, requesting that the sending apparatus send 
a prescribed encryption parameter. 
[0023] Another aspect of . the present invention pro- 
vides a method of distributing encrypted content infor- 
mation, via a network in accordance with a prescribed 
10 transport protocol, to other end apparatus in a commu- 
. nication authenticated by an authentication process in- 
cluding at least one procedure of an authentication pro- 
cedure and a key exchange procedure, comprising the 
steps of: (a) encrypting content information encoded by 
*5 a prescribed encoding system; (bj adding an.encryption 
attribute header including attribute information with re- 
gard to the encryption of the content information to the 
encrypted content information; (c) adding a content at- 
tribute header, indicating attributes of the content infor- 
ms.- mation lo content information, to which the. encryption 
. - attribute header has been added; (d) performing trans- 
^ - port protocol processing required to transfer the content 
; . r information, andadding a basic transport header to.con- 
•tent information to .which the content attribute header 
25 has been added; . and (e). sending a packet including the 
r r basic. transport header, the encryption.attribute header, 
I : ,.the content attribute Jneader, and .the encrypted content 
, . information to the other endrauthenticated apparatus, 
wherein the encryption attributeheader is set into either 
30 _ an expansion transport header within a, packet header 
, of the packet, or into a payload header within an encrypt- 

ed payload of the packet..; ; t - v/.---';; ;■-?■<■ v' 
: ... ,[0024] ^Another aspect of the present invention, pro- 
yides a method .of distributing encrypted content infor- 
ms. _ mation, via a -network . in -accordance with a prescribed 
.. . transport protocpl,[t0 9ther end apparatus in the com- 
munication authenticated by. an authentication process 
s t . including at least one procedure^ of. an. authentication 
. . ( . ..procedure and-arkey exchange .procedure, comprising 
the steps of: (a') adding a.content .attribute.header.indi- 

- v eating attributes of the content information to the content 
. .information to.be transferred; (b') encrypting content in- 

, formation that are encoded by a prescribed encoding 
... , system and to which the jN cpntent attribute header, has 
45^ .been .added; (c;) adding to the encrypted content infor- 
matjon an encryption attribute/header-including attribu- 
i: , tipn information with regard.to the encryption of the con- 
tent- information; (d 1 ); performing transport; protocol 
processing required to transfer the content information, 
so and adding a basic transport headerto content, jnforma- 
- tion to.which the encryption attribute, header has been 
v . added; and (e^) sending .a r , packet .including 1 the basic 
.transport header, the encryption attribute header, the 

- < content. attribute header, and the encrypted content in- 
ss, formation to the other end authenticated apparatus, 

wherein the encryption attribute header is,set into either 
. an expansion transport header within a packet header 
, of the packet, or into a payload header within a payload 
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to be encrypted of the packet. 

[002S] Another aspect of the present .nvention pro- 
vides a method of receiving encrypted content informa- 
tion via a network in accordance with a prescribed 
transport protocol, by an authentication process includ- 
ing at least one procedure of an authentication proce- 
dure and a key exchange procedure, comprising the 
steps of: (aa) receiving a packet including a basic trans- 
port header, an encryption attribute header including en- 
cryption attribute information with regard to the encryp- 
tion of the content information, and encrypted content 
information; (bb) referring to the basic transport header 
and judging whether or not the content information is 
encrypted or whether or not there is a possibility that the 
content information is encrypted; (cc) referring to the en- 
cryption attribute header and extracting encryption at- 
tribute information with regard to encryption of the con- 
tent information; (dd) referring to an expansion transport 
header within a packet header of the packet and extract- 
ing content attribute information with regard to the con- 
tent information; and (ee) in the case in which a judg- 
ment is made at (bb) that the content information .s en- 
crypted, decrypting the encrypted content information, 
based on the extracted encryption attribute informat.on. 
[0026] Another aspect of the present invention pro- 
vides a method of receiving encrypted content informa- 
tion via a network in accordance with a prescribed 
transport protocol, by a authentication process including 
at least one procedure of an authentication procedure 
and a key exchange procedure, comprising the steps 
of (aa 1 ) receiving a packet including a basic transport 
header, an encryption attribute header including encryp- 
tion attribute information with regard to the encryption 
of the content information, and encrypted content infor- 
mation- (bb' ) referring to the basic transport headerand 
judging whether or not the content information is en- 
crypted or whether or not there is a possibility that the 
content information is encrypted; (cc') in the case in 
which a judgment is made at (bb") that the content infor- 
mation is encrypted, referring to the encryption attnbute 
header and extracting encryption attribute informat.on 
with regard to the encryption of the content informa t.on; 
(dd 1 ) in the case in which a judgment is made at (bb ) 
that the content information is encrypted, decrypting the 
encrypted content information based on the extracted 
encryption attribute information; and (ee') referring to an 
expansion transport header within a packet header of 
the packet and extracting content attribute information 
with regard to the content information . 
[0027] Another aspect of the present invention pro- 
vides a computer-readable recording medium for re- 
cording a program to be executed by a computer, the 
program performing distribution of encrypted content in- 
formation, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a commu- 
nication authenticated by an authentication process in- 
cluding at least one procedure of an authentication pro- 
cedure and a key exchange procedure, the program 



comprising: (a) a module for generating an encryption 
attribute header including attribute information^ with re- 
gard to encryption of the content information; (b) a mod- 
ule for performing transport protocol processing re- 
quired to transfer the content information and for gener- 
ating a basic transport header to be added to the confer, 
information to which the encryption attnbute header has 
been added; and (c) a module for sending a packet in- 
cluding the basic transport header, the encryption at- 
tribute header, and the encrypted content informaton to 
the other end authenticated apparatus, wherein the en- 
cryption attribute header is set either into an expansion 
transport header within a packet header of the packet 
or into a payload header within a payload to be encrypt- 
ed of the packet. 

[0028] Another aspect of the present invention pro- 
vides a computer-readable recording medium for re- 
cording a program to be executed by a computer, the 
program performing receiving of encrypted conten t ,n- 
!ormation,viaanelworkinaccordancew,lhaprescr,bed 

transport protocol, by an authentication process includ- 
ing at^ least one procedure of an authentication proce- 
dure and a key exchange procedure, the program com- 
prising: (aa) a module for receiving from a sending ap- 
paratus a packet including a basic transport hoador, an 
encryption attribute header including attribute informa- 
tion with regardto encryption of the content information 
and encrypted content information; (bb) referring to the 
basic transport header or the encryption attribute head- 
er and judging whether or not the content information is 
encrypted or whether there is a possibility that the con- 
tent information is encrypted; and (cc) in the case in 
which a judgment is made by module (bb) that the con- 
tent information is encypted. decrypting the encrypted 
content information based on attribute informat.on w. h 
regard to encryption included in the encryption attnbute 

IfOoSi Other features and advantages of the present 
invention will become apparent from the following de- 
scription taken in conjunction with the accompanying 
drawings. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0030] The accompanying drawings, which are incor- 
porated in and constitute a part of the specification, il- 
lustrate presently preferred embodiments of the inven- 
tion and together with the general description given 
above and the detailed description of the preferred em- 
bodiments given below, serve to explain the principles 
of the invention, wherein: 

Fig 1 is a drawing showing an example of a config- 
uration of a network associated with the first em- 
bodiment to the sixth embodiment of the present in- 
vention; . 
Fig 2 is a diagram showing an example of a se- 
quence of content distribution in the first embodi- 
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ment to the sixth embodiment of the present inven- 
tion; 

Fig. 3 is a block diagram showing an example of the 
configuration of an MPEG distribution server ac- 
cording to the first embodiment of the present in- 
vention; 

Fig. 4 is a flowchart showing the procedure for con- 
. , tent distribution processing in an MPEG distribution 
server according to the first embodiment of the 

• present invention; 

- Fig. 5 is a drawing showing a first example of.a for- 
mat of a code expansion header; : : . 

fc : - Fig. 6 is a drawing showing a first example of the 

• ■ : \ format of a header given by an RTP processor; 

- . ,; : ; - > Fig. 7 is a drawing.showing a first example of a for- 

mat of a transferred I P packet; 
Fig. 8 is a block diagram showing an example of the 
configuration of a receiving apparatus according to 
the first embodiment of the present invention;- 
" F'9-. 9. is a flowchart showing the procedure for con-:, 
tent receiving processing in a receiving apparatus 
; ^according to the first embodiment of the present in- 
... / vention;- , ;> - ■. \ - ; - , • - . * 

. Fig. 10 is a block diagram showing an example of 
- . ^j- ■ •■ the configuration of ah MPEG distribution server ac- 5 . 

: cording to the second, third, or fifth embodiment of 
v:. ■ • the .present, invention;. ( r . - •.. 4 . ;-\ & 

Fig. 1.1 is a drawing showing a second example of 
- t y w . a format of a header given by .an RTP processor; 
.- *> Fig. 12 is a drawing showing the. second example. 
\ r: i , of the format of a transferred IP packets 

ta u ^'9* ? is a flowchart showing the procedure forcon- 
>r •;; ■•; tent distribution processing in an MPEG distribution 
v, server according tp trie second>embodiment of the 
present invention; .-, ■■ _ : . ■ *<. 

r. . Fig: 14 is a block diagram showing an example of 
r • ^. the configuration^of a receiving apparatus accord- 
ing to the second, third, :or fifth embodiment of the 
■y. .j/ present invention; \v/- 

• ; - Fig. 15 js a flowchart showing the procedurejprconr 
tent receiving, processing in a receiving apparatus 
k . ( according to the second embodiment of. the present 
cv _ ^invention; ■ . v- - — \ rcr " \ 

.Fig. :16 is a drawing showing a third exampleof a 
• > format of a header given by an RTP. processor; . 

r f!9-. 17 's a drawing showing a, third example :of a 
. tl : format of a transferred IP packet; • ■ v. H : : - 

Fig. 18 is a block diagram showing an example of 
I..- . the configuration of an MPEG distribution server ac- 
— _' .cording.to the fourth or sixth embodiment of the. 
r . . present invention; > ., ; ^. . , * 
...7, ; Fig. 19 is a drawing showing a fourth example of a 
format of a header given by an RTP processor; 
. . Fig. 20 is a drawing showing a fourth example of a 

format of a transferred IP packet; J . ■/ 
■ - .Fig. 21 is a flowchart showing a procedure for con- 
• tent distribution ; processing in an MPEG distribution 
server accprding.tp the fourth embodiment of the 
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present invention; 

Fig. 22 is a block diagram showing an example of 
the configuration of a receiving apparatus accord- 
ing to the fourth or sixth embodiment of the present 
invention; 

Fig. 23 is a flowchart showing a procedure for con- 
tent receiving processing in a receiving apparatus 
according to the fourth embodiment of the present 
invention; 

Fig. 24 is a drawing showing a fifth example of a 
format of a header given by an RTP .processor; 
Fig. 25 is a drawing showing a second example of 
a format of a code expansion header; 
,Fig. 26 is a drawing showing a fifth example of a 
format of a transferred IP packet; , \\ - 
Fig. 27 is a drawing -showing a sixth example of a 
, format of a header given by an RTP. processor; 
( Fig. 28 is a drawing.showing a sixth example of a 
formatof a transferred IP packet; . ; .--.( 
. Fig. 29 is a drawing showing.an example of the con- 
figuration of a network-according to the seventhiem- 
bodiment of the present invention;*/.; 1 -*, . - 
Fig. 30 is a.drawing showing an example o.f.the se- 
quence of content distribution according to.the sev- 
enth embodiment of the present invention;.^ 
Fig.. 31 is a block diagram, showing : an, example of 
r ; the configuration of an MPEG distribution serve rac- 
.w- cording to the seventh embodiment of the; present 
- . invention; ,;>". r, ■. r ~.v/ >< : - »«•?.-.• . 

Fig. 32 is a drawing showing a;seventh example of 
: a format of a transferred I P. packet; -.>«:. - 
» , Fig. 33-is a drawing, showing a seventh, example of 
:a format of a header given by an RPT processor; 
.'Fig., 34 is a block diagram showing an v exam pie of 
the configuration of a receiving apparatus. accord- 
...ingto the seventh embodiment of the present inven- 
. ; tion;-ancJ ' .:*:'/ r. , v~'.: - <:j >■ . 
•S..; ^Fig. 35 is adrawing showing an example of the se- 
quence of- content distribution according to the 
r : : . eighth .embodiment. of the present invention! : 

. n' - ' ^v'i: ' f . 

DESCRIPTION OF .THE PREFERRED. • 
.EMBODIMENTS .. , V ^ . • 

:.v t-,,; : :Vr, j//-.- »v.,f,|r/ * : 
[0031] • Embodiments of a content distribution appara- 
tus, a.content receiving apparatus, and a content distri- 
bution method. according to the present 'invention are 
.described in detail .below, with reference to- Fig. 1 
'through Fig.. 357. - . i' ■ . 

First Embodiment . , *- ,■„■■ 

[0032] . The first embodiment of >a content distribution 
apparatus, a contentreceiving apparatus, and a content 
.distribution method according to the present invention 
is described in detail below, with reference to Fig. 1 
through Fig. 9.-: ■ ? ' 

[0033] Fig.,1 shows an example of .the configuration 
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ol a content distribution system according to this em- 
bodiment ol the present invention. In Bfr Mn «G 
distribution server 101 and a rece.v,ng W"™^ 
according to this embodiment are connected to the In 
fernet 03, MPEG4 AV stream data being securely corn- 
Sated between the MPEG4 distribut.on server 101 

L the receiving apparatus 102, via the Interne 03. 
Ol course, other MPEG4 distribution servers and receiv- 
ing apparatuses and other types of equipment can ad- 
diUonally be connected to the Internet 103. 
fS In the description of embodiments to follow, 
Khe type of data is MPEG (Motion Picture Expert 
Group)4, itwill be understood that the present. nven.ion 
to not , restricted to application to this type of data, and 
can be applied to other data types as well 
?003S1 The MPEG4 distribution server 101 performs 
Sbution of MPEG4 data to the receiving apparatus 
102 MPEG4 data Is distributed no. in the form ol We 
ransfer but rather as data stream. The MPEG4 data 
ha"tlo be copyright protected is distributed m encrypl- 
Td orm When'dotng this, an authentication procedure 
or key exchange procedure is performed between the 
MP EG 4 distribution sender 1 01 and the rece,v,ng appa- 

S^Tho sequence of this procedure is illustrated 

clSn and authentication, and it should be noted that 
£1V such asthelPlayer and transport .aye 
and Authentication procedures in those layers have 
been omitted from this drawing, as has the procedure 
f or assessing charges at the content layer, which ,s per- 

assessment and authentication/encryption at other lay 

5S "Sr^ case in which the receiving ap- 
paratus 102 makes a request to the MPEG4 d.stribut.on 
SSTlOT for distribution. In this case, the first authe- 
tication request is sentfrom the receiving apparatus! 02 
S201 ) In this authentication request, there can also be 
a simul aneous exchange of a certificate (equipment 
certSn)that is received by the apparatus (receiving 
aooaSus I02)fromacertification organizat.on, thecer- 
EJcertifyiig that the equipment is capable of per- 
forming transfer of copyright protected content. 
ro0391 The "equipment ID" that is used .n the equip- 
nCcertKicaJ can be an IP a^^^J- 
in which the IP address is given by a DHCP (Dynam 
^Configuration Protocol) server.there 
that this value will differ each time the apparatus is boot- 
ed Because of this situation, it is possible tc >use -m the 
"eauioment ID" for equipment certification the MAC ad- 
dress onhe equipment, or the EUI64 address, or an ad- 

ule number. It is further possible to use as the equip- 
mlrt ID" the CPU ID number of the apparatus, or the 
MPEG4 decoder .D number or the .ike, which (ideally) 
is a value that is unique worldwide (or that can be ex- 



pected to be unique or almost unique within the region) 
rnodOl An MPEG4 distribution server 101 that re 
52 a message from the receiving apparatus 101 
perfo ms a response to the authentication request and 
5 performs exchange of a certificate (equipment certifica- 

SSlf Next, the MPEG4 distribution server 101 and 
he receiving apparatus 1 02 perform a process that gen- 
SSHJStw^ key, for the purpose of gener- 
S a common authentication key (fW-DJ** 
"h s procedure can be the same as. for example the 
FEE 1394 copy protection key generation process. 
When hTp ocess'is compieted, the MPEG4 (Mnbo- 
«w*r 101 and the receiving apparatus 102 can 
J5 possess a ZZ authentication key Kauth, which ,s 

sends G(Kx. Kauth) which is generated by certain func- 
2 G w th the use of an exchange key Kx. the authen- 

20 ■ atfonty Kauth as <^Z*£«£fi£ 
Nctothe receiving apparatus 102 (S204. S20J At me 
deceiving apparatus 102, reverse function of G(Kx 
Kauth) is emulated so as to extract the exchange key 

25 TO043] At this point in time, the MPEG4 distribution 
lerve 101 and the receiving apparatus 102 share he 
three values of authentication key Kauth, exchange key 
Ky and the random number Nc. 
moS At this point, the encryption key (content key) 
so Kflich is the encryption key for encrypting the 
MPEG4 data to be sent by the MPEG4 distribution serv- 
er 101 and for the receiving apparatus 102 to decrypt 
L receded encrypted MPEG4 data (that ,s the shared 
kev Ts calculated in the MPEG4 distribution server 101 
35 and the receiving apparatus 102, respectively, by using 
one and the same pre-established function J, as a tunc- 
ton of part of the above-noted value. For example the 
alcu aS is made as Kc=J[Kx. f(EMI), Nc] m which 
EM indicates the copy attribute for the data (content), 
40 which expresses such attributes as the data bein co- 
Sle without limit, the data being copiable onty 1 time, 
Sedate being copiable only 2 times, the data be,ng un- 

copied and therefore not further copiab e. f(EMI) * 
45 tained by transforming the attribute value of EM with 
he use of certain specific function f . These functions J 
Tndf can also be kept maintained as secret with respect 

SET HZ the encryption key (content key) Kc is 
50 Sated theMPEG4distributionserver 1 01 encrypts 
C content (MPEG4 data) using the encryptior ikeyKc, 
and sends the encrypted content to the Internet (S206, 
S207 ) 

r 0 046] " As will be described below, because the en- 
55 crypted content is in the form of AV stream data ^rans- 
£?red in real time over the Internet, in the f.*t errtxxfc- 
mert of the present invention FfTP (Real-time Transport 
Protocol) is used as the transport protocol. 
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[0047] It is also possible to make the encryption key 
Kc vary with time (that is, have its value change with the 
passage of time). 

[0048] For example, if the elapse of a prescribed 
amount of time (which can be a fixed amount of time, or 
a variable amount of time) from the previous change is 
recognized, the value of the variable Nc js incremented, 
. and the above-noted function J is used to calculate the 
. ..encryption key Kc. When this. is done, the timing of up- 
dating of the encryption key Kc value (or the data at the 
point at which the encryption key.Kc is to be updated) 
must be recognized synchronously at the sending and 
receiving sides. For this reason, regions such as Even/ 
Odd field is provided in the transferred MPEG4 data (AV 
, data), and the point at which there is a change .in the 
field is established as the point at which the value of the 
. variable Nc; that is, the value of the encryption key Kc 
. is changed, so that data after the field .change point is 
. ,,encrypted with the updated encryption key Kc. . .. 
r . [0049] ; . The MPEG4. .distribution server 101 .monitors 
the above-noted elapse of time and, when the timing for 
, : the updating .of the encryption key Kc is detected, the 
* value of the variable Nc is r incremented and the encryp- 
, .tion key Kc.is calculated again, the recalculated .value 
, of tho encryption key Kc being used, to encrypt the 
... MPEG4 data that is "to be sent, the Even/Odd field value 
being incremented, and transmission. being performed. 
-- Thereafter, until the timing for the next updating, this up- 
.- dated ^encryption key Kc is 'used to perform encryption. 
Vt: ;.[0050] r ^At the receiving apparatus 102, the received 
; ; Even/Odd field value is monitored, comparing the value 
with the immediately previously .received value and, if 
.... the value is detected as being different from the imme- 
diately .previously received value,, the value of the vari- 
f -able.Nc incremented, and the value of encryption key 
... ;Kq; is recalculated, the encryption key Kc after this re- 
\ .calculation being used in decrypting received encrypted 
data. Thereafter, until the next change in the Even/Odd 
. . afield value is 'detected,. this value of encryption .key Kc 
'is used to "perform decryption.. - ^ . ..- •• '-.•-»■ 
. J0051], In this -manner,, encrypted. MPEG4 data is 
, r transferred between the' MPEG4 distribution server 1 01 
; ; and the receiving apparatus. 102. w , . 
; f0052] Fig" 3 , shows an example! of/the- internal con- 
figuration of .the MREG4 distribution server 101 ■ 
[0053]. As shown 'irv Fig" 3,' the."MPEG4 distribution 
. server. 1 01 of .this.embbdiment comprises a MPEG data 
\ . generator 301, a data encryplor 302 r an RTPprocessor 
, . 303, an' RTCP transmitter 307, a TCP/IP and UDP/IP 
. . processor. .308, a link/physical layer. processor 309, an-, 
... . jRCJR receiver/interpretep 31 0, and an authentication/ 
. . key exchange processor 31.1 . The. RTP^ processor 303 
• includes an. encryption expansion header adding unit 
304, an MPEG4 expansion header adding unit 305, and 
. .an RTP basic header, adding unit 306, and performs 

processing 'related to the RTP. . , 
- [0054] . Next, the procedure for processing the content 
distribution in the . MPEG4 distribution server 101 ac- 



cording to the first embodiment is described below, with 
reference.to Fig. 4. 

[0055] Processing related to authentication and en- 
cryption in the sequence of Fig. 2 (processing from S201 
5 to S205) and processing related to Ihe above-described 
updating of the encryption key is performed by the au- 
thentication/key exchange processor 31 1 . This process- 
, ing can be performed before or after the sending of con- 
tent to the receiving apparatus 1 02. 
10 [0056] . The inputted AV information (for example,, an 
analog signal) is compressed to MPEG4 data by the 
MPEG4 data generator 301. - 
[0057] When this is done, if MPEG attribute informa- 
tion such as the location of I pictures (jntra-coded pic- 
15 tures) and the encoding rate are sent simultaneously 
with the MPEG4 data to notify ,the receiving side, play- 
back (decoding) atthe receiving side is facilitated. In 
particular on the Internet, where such things as discard- 

• ed and delayed packets and a change in the sequence 
20 .of arrival of packets canoccur, this attribute information 

, is essential to achieve high-quality playbackat the re- 

- ■ xeiving side. For example, in the case.of MP.EG4 in .the 

• first embodiment,;, information about, for example, "the 
VOP header corresponds to these attributes. Gases can 

25 T .be envisioned in which information with regard to the 
MPEG4 system, for example transmission- efeynchro- 
r nization information ata sync layer, information fonmul- 

- tiplexing when sending a plurality of MPEG4 streams in 
multiplexed format, or information with regard.to initial 

30 - r and latest values of object descriptors is required:. For 
this reason, when sending AV data by RTP, the above- 
noted information is coded;. inta the .RTP; expansion 
: header or into the paylqad header .of the RTP pay load 
. (that is, user area), so that the MPEG attribute.informa- 
35. tion is sent-along with^the AV.data.-./, -•<■ : ?- : . r: 
[0058] ln thefirstembodiment,.this MPEG attribute in- 
■ formatjqn is sent in the form.of an RTP .expansion -head- 
; er. That is, it is sent as an RTF? expansion header of, the 
j • |D type of MPEG4 expansion-header. For this reason, 
^0 . . required information with regard to encoding is sentf rom 
, r the ,MPEG4;data generator 301 as notification .to.. the 
.MPEG4,expansion,header adding unit 305;- 
.. [0p59] Next, f , the /MPEG4. data outputted Jrom- the 
; : MP.EG4 data generator 301. is encrypted by the data en- 
45 ..cryptor 302 (step S401 in Fig.,4). When this is done, the 
, encryption key may be the above-noted time -variant en- 
• ../.cryption key Kc. With regard to the encryption. process- 
J ing as weli, avariety^of attribute information can be en- 
visioned. In .the .first embodiment, an RTP expansion 
50 header whose ID type indicates the?encryption-expan- 
sion header isadded by the encryption expansion head- 
er adding unit 304. (step S403). For this reason, infor- 
r mation required for the generation of an encryption ex- 
pansion header is sent as notification from the data en- 
55 - crypter 302 .to the encryption expansion header adding 
unit 304. . - , ' ; 

- t°°60] In order to perform the above-noted encryption 
processing, at the authentication/key exchange proces- 
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sor 311 when the timing for updating the encryption key 
£ is reached, Nc is incremented and the above-de- 
scribed function J is used to generate a new encryption 
S Kc whteh is passed to the data encrypter 302 Along 
with this the value of Even/Odd field is incremented and 
passed io the data encrypter 302. The value Even/Odd 
Seid is passed, as noted above, from the da j, anjgjr 
302 to the encryption expansion headeraddmg un.t 304. 
E Rg. 5 shows an example of an encryption ex- 
SSJn header. The encryption expansion header -h- 
a expansion header type field, a encryption onM field, 
encryption type indication field, an encryption mode in- 
dicator (EMI ) field, and an Even/Odd field. 
S The expansion header type field is for coding 
nformation that indicates the type of corresponding ex- 
pTnsTon header. In this case, information MnM« 
,he encryption expansion header is coded into the ex 

nformation indicating whether or not the data ref- 
erred in the corresponding RTP packet is encrypted 
5£ The encryption type indicator field is a eld for 
coding the type of encryption used with respect to date 
transferred in an RTP packet. For example in Fig. 5, 
formation is described that indicates "an M6 oncryp- 

The encryption mode indicator (EMI) field is a 
Sd for coding the above-noted copy attribute value 

The Even/Odd field, as noted above, is a field 
lor notifying the receiving side from the sending s.de of 
the timing of updating of the encryption key. 
m0671 Although in the example shown each field has 
there is no restriction to the number of bits, and 
the number of bits can be appropriately established as 

Si" When AV data is encrypted and sent to the re- 
ceiving side, if it is desired to perform such trick play as 
Lt-forwarding. or sending of partial static images there 
are cases in which processing at the recerv.ng side be- 
Tmes difficult. This is because it is difficult* , perform 
a task such as sending just a part of an encrypted AV 
data st earn (for example, because the Nc value wou d 
not be incremented but would rather skip over a number 
lvalues). Forthis reason, in certain cases .t.s desirable 
to sen AV data to the receiving side without encrypting 
it tn such cases, it is necessary to notify the receiving 

been encrypted. The above-noted encryption on/off field 

is provided for such purposes. 4ho „„ esi 
r 0 069] Additionally, on the internet there is the possi- 
bility that one stream will use one encryption type and 
arShe stream use a different encryption type. In such 
cases if there is a field that indicates to what type of 
encryption the AV data has been subjected, the receiv- 
es de can examine this field so as to select a preper 
decryption engine for describing the data. Tne above- 
noted encryption type indicator field .s provided for this 



Soj 'as shown in Fig. 5, the encryptbn mode indi- 
ca°or (EMl) field is 8 bits rather than the 2 bits .ha are 
used in the case of IEEE 1394. This is in order to estab- 
s !sh the freedom to select a value of N used to give no- 
fcaSon of the specification of the number of copies N 
d S aV data that are to be permitted, and for cases in 
which a special type of copying (for example, permitting 
555 Z "wnen'some condition is -^^jj* 
,o case this field must be able to take a larger number of 
values than would be possible with 2 bits 
[0071] As shown in Fig. 5. in the Even/Odd fieta, m 
con rest to the 1 bit used in IEEE 1394, there are 8 bits 
P Sd This is because 1 bit would not allow enoug 
is information for the Internet, in which as noted above 
is possible to have discarded or delayed packets and 
an altered sequence of packet arriva.s. Thus for exam- 
p e on the Internet a case can be envisioned ,n wh if, 
with the Even/Odd bit 1 as shown at step S207, all the 

were to be just 1 bit, the Even/Odd field would return to 
0 a the next packet, so that as seen from the receiving 
sidlThe condition in which the Even/Odd bit is 0 ■ eon- 
t inuing (that is, not changing). Thus, although Nc should 
tinumgiuioi if the Evon/Oddbitvaluo 

ss actually bo incremented by 2, it tno tvon '^ 

is not changed, the Nc value is not incremented, thereby 
preventing generation of the correct encryption key. Be- 
cTse o SJ situation, more than 2 bits, for example 8 
S are provided in the Even/Odd field, so tha even 
30 packet discarding and delay, or resequence? ,0 packet 
arrival occurs, as it can on the Internet, it is possible to 
perform appropriate processing on the receiving side 
f 0 o72] in the first embodiment of the present inve - 
° n data encryption is performed 
35 MPEG4 data itself, and not ^"^ 4 **^ 
expansion header. Because the MPEG4 expansion 
header is not content that need to be copyright protect- 
ed M is rather used on the receiving side before the 
MPEG4 data itself is used, enabling it to omitted from 
40 the data that is encrypted. 

r0073] in the RTP processor 303. an encrypt on ex- 
S2n header is added to the MPEG4 data by the er, 
cryption expansion header adding unit 304, an , MPEG4 
exSnsion header is added to the MPEG4 data by the 
45 expansion header adding unit 

in F ig 4), and an RTP basic header is added to the 
MPFG4 data bv the RTP basic header adding unit 306 
S^tSln^a^b-nBtl.^-*- 
m 'header such as shown in Fig. 6. The encrypt. on 
50 expansion header is generated based on information 
ShTdkencrypter302.andtheMPEG4e = s^ 

header is generated based on information from the 
date generator 301, The RTP header has £ 
m ents that are basic parameters required for AV date 
55 transfer via the Internet, such as * 
sequence number (for details, refer to * FC 1889 >_ 
r00741 Encrypted MPEG4 date to which the RTP 
ES has been added is sent to the Internet 103 by 
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the TCP/IP and-UDP/IP processor 308 as an IP packet 
as shown in Fig. 7, via the link/physical layer processor 
309. 

[0075] Next, the configuration of the receiving appa- 
ratus 102 and the procedure for processing therein will 
be described. 

t [0076] , Fig. 8 shows the internal configuration of the 
receiving apparatus 102. 

[0077] As .shown in. Fig. 8,. the receiving apparatus 
1 02 according to the first embodiment comprises a link/ 
physical layer processor 701, a TCP/IP and UDP/IP 
processor 702, an RTP processor 703, a data encryptor/ 
decryptor707, anMPEG4data decoder 708 -a receiving 
condition interpreter 709, an RTCP transmitter 710, and 
an authentication/key exchange processor 711.. The 
:RTP processor 703 includes an RTP basic header re- 
. ceiver/interpreter704, an MPEG4 expansion header re- 
,ceiver/interpreter 705, and an encryption expansion 
header receiver/interpreter 706, and performs process- 
ting related to the RTR* .., -\- '■ .v 
[0078] Fig. 9 shows a procedure for encrypted content 
, receiving processing, performed by the receiving-appa- 
.... ratus 102 of the first embodiment of i the present inven- 
. tion. ... -j \ ■ + 
.... [Q079]. Processing related 4o. authentication and en- 
cryption of the sequence of Fig. 2 (processing from S201 . 
.to S205) and processing related to encryption - key., up- 
dating is performed by the authentication/key exchange 
processor 711. • ... ik % ~ , k . - 
[0080] , The receivings-apparatus 1 02 -basically per: j 
: - forms processing in a sequence that is the reverse of 
.. the processing performed by the >MPEG4,distribution 
/ server 101". - f: v; ~ ' , . • 

[0081]: Specifically, MPEG4 data (encrypted data with 
V an added RTP header) transferred via-the Internet 103 
passes through the link/physicaMayer processor 701 to 
} ; the TCP/IP.and UDP/IP .processor .702 and is then in- 
. putted to the RTP processor 703 (step-S901 in .Fig. 9). 

[0082] At the RTP processor 703, the RTP basic 
. - . header is interpreted by the RTP basic header receiver/ 
. t interpreter.704 (step S903 in Fig. 9), the MPEG4 expan- 
sion header is interpreted by the MPEG4 expansion 
^ ..header receiver/interpreter705 (Step . S905), and the 
encryption expansion header is interpreted by the. en- 
cryption -expansion header receiver/interpreter 706 
- (Step S907). Jnformation .required for decoding is sent 
as notification from the.MPEG4 expansion, header re- 
■ , . ceiver/interpreler.705 to the MPEG4 daladecoder 708, 
and information, required for decryption is.sent from the 
• encryption expansion header receive r/interpreter.706 to. 
-the data encyptor/decryptor 707. • ; * ~- r . 

[0083] . The encrypted data. stored, in the RTP payload 
is passed-from the' RTP processor 703 to the data^en- 
cryptor/decryptor-707. The data encryptor/decryptor 
707 performs decryption of data : based on. information 
from the encryption expansion header receiver/inter- 
preter 706, ,i" - r ' " 

[0084], The encryption key used in decryption is the 



above-described time-variant encryption key Kc. That 
is, the data encryptor/decryptor 707 refers to a value of 
the encryption on/off field of the encryption expansion 
header sent as notification from the encryption expan- 

s sion receiver/interpreter 706, so as to learn that the re- 
ceived data is encrypted (as a result of which the de- 
cryption thereof is determined), after which the Even/ 

. Odd field is referenced and a. comparison is made be- 
tween the value thereof and a previously received value. 

io . |f the value had been an increment, it is known that the 
encryption key is to be updated (but if the values are the 

"■; same, .the encryption key will not be updated). Then, the 
fact that the encryption key is to be updated is notified 

• to the authentication/key exchange.processor 711 from 

1$ the data encryptor/decryptor 707, and in the authentica- 
' tion/key exchange processor 71 1 -since/the timing for up- 
. .dating the ; encryption key Kc has been reached, Nc is 

- incremented and the above-noted. function J is used to 
^generate -a, new-encryption key Kc, which is passed to 

20 - the data encryptor/decryptor 707.. v: .. 
, [0085] Decrypted MPEG4 data is passed from the da- 
te encryptor/decryptor 707 to the MPEG4 data ; decoder 
708. The MPEG4 data decoder. 708 .. decodes , this 
- ; MPEG4 data, based on information from the MPEG4 ex- 
2f . pansjon header receiver/interpreter 705, , and outputs 
, : . the results as an AV output data (for example-an-analog 
. -signal). . . . • * • . .'. 

[0086]. In the above, the RTP has associated with it 
- ( . RTCP (Real-time Transport Control, Protocol). . RTCP 
3 ? „ vr T]°. n ' tor s the RTP sequence number, and time stamp 
^ : -and has the function of notifying the sendingside (in the 
first embodiment, -the MPEG4 distribution server 101) 
from the receiving sidejin the first embodiment, the re- 
r ceiying apparatus 102) with regard.tothe receiving con- 
35 ,dition (packet disca_rding rate, packet transmission de- 
v lay time, and the like). This.is performed by the receiving 
: V: condition interpreter 709 and the RTCP transmitter 71 0. 

; : [0087] The MPEG4 distribution server 101. receives 
r ; . this RTCP packet aMhe RTCP receiver/interpreter 310 
to and, if necessary, can apply feedback to the MPEG4 da- 
ta generator 301 , to attempt to achieve optimization. For 
example, in the case in which there, is a great amount 
of packet discarding, network crowding can be ehvi- 
stoned,. in : response to which the bit rate of the MPEG4 
4$ data generation can be lowered by feedback. 

[0088] The PTCP transmitter 307 of.the MPEG4 dis- 
. .aribution. server .101 transmits information required for 
RTGP. . v 

[0089] . .On the other hand, as described.above, in the 
50 ; receiving apparatus 102 based on the results of: moni- 
toring the Even/Odd field included in the encryption ex- 

- pansion header- of the received packet, the value of the 
. variable Nc used in the calculation of the encrypt, ion key 

.. Kc is- changed. Therefore, if it is not possible for the 
55: .sending side to reliably inform the receiving side that the 
. value of Nc has-been updated, the receiving side cannot 
calculate the encrypt ion key Kc, thereby making.it im- 
possible to decrypt the arriving encrypted data. 
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r0090] Because the Internet is intrinsically a network 
on which discarding of packets can occur, it is not guar- 
anteed that the meaning of the Even/Odd field value 
(timing of incrementing) will be accurately informed to 
he other apparatus in a communication link (parteularty 
in the case in which there are few bits in the Even/Odd 
field) Because of this situation, in the case in which the 
receiving apparatus 1 02 wishes to know the precise val- 
ue of Nc it can be provided with the option to issue a 
request to the sending apparatus (in this embodiment, 
the MPEG4 distribution server 101) for the Nc value. 
[00911 As an example of a case in which the receiving 
apparatus 102 wishes to know the precise Nc value, 
consider the case in which there is more skipping than 
expected in the time stamp or the sequence number of 
the RTP basic header, in which case one solution envi- 
sionable is that of sending a packet to the sending side 
to request the value of Nc. This is because a skip greater 
than a pre-established limit could mean the possibility 
that the Even/Odd bit value has changed. This process- 
ing is performed by the authentication/key exchange 
processor 311 of the MPEG4 distribution server 101 or 
the authentication/key exchange processor 711 of the 
receiving apparatus 102. By doing this, even in the event 
that synchronization of the Even/Odd bit is lost between 
the MPEG4 distribution server 1 01 and the receiving ap- 
paratus 102, it is possible to perform appropriate recov- 
er processing. Furthermore, in the case in which there 
is notification of Nc value from the MPEG4 distribution 
server 101 to the receiving apparatus 102. it is possible 
to simultaneously send the time stamps and sequence 
numbers ol the corresponding RTP, expansion header, 
or payload header as notification. 
ro092] A case can be envisioned in which distributed 
data is accumulated in the receiving apparatus (or in 
some form of storage medium, such as DVD-RAM or 
the like, installed in the receiving apparatus), in which 
case the distributed data can be stored as is in the form 
of encrypted data, and the corresponding encryption 
key Kc stored together therewith. 

Second Embodiment 



ro0931 Next, the second embodiment, in which there 
is a varation of the packet format in Ihe first embodi- 
ment is described below, with reference to Fig. 10 
through Fig. 15. Because the basic configuration and 
operation ol the second embodiment is the same as that 
of the first embodiment, the description that follows fo- 
cuses on the differences introduced with the second em- 
bodiment compared to the first embodiment 
r00941 The difference in the second embodiment with 
respect to the first is that, whereas in the first embodi- 
ment an encryption expansion header and MPEG4 ex- 
pansion header were added as expansion header in an 
RTP header (Fig. 6 and Fig. 7), in the second embodi- 
ment the encryption expansion header .the 
expansion header in the RTP header and the MPEG4 



expansion header is added as a payload header to the 
RTP payload (Fig. 11 and Fig. 12). 
ro0951 The overall network configuration according to 
he second embodiment is similar to that of the first em- 
5 bodiment (Fig. 1 ). The processing sequence hs also sim- 
ilar to that of the first embodiment (Fig. 2) The encryp- 
tion expansion header format is also similar to that of 
the first embodiment (Fig. 5). 
r0096] Fig. 10 shows an example of the configurator. 
,o of an MPEG4 distribution server 101 according to he 
second embodiment. In this embodiment, because the 
MPEG4 expansion header is provided as a payload 
headerforthe RTP payload, the processing for applying 
the MPEG4 header is removed from the RTP process- 
75 inq so that the MPEG4 expansion header add.ng unit 
SdFig 3 is removed from within the RTP processor 
305 and placed outside, this becoming the MPEG4 pay- 
ioad header adding unit 315, which is different than in 
the first embodiment. 
20 0097] Fig. 11 shows the formal of the RTP header 
used when sending encrypted AV data in the second 
embodiment. In the second embodiment, a payload I type 
field that indicates an attribute of data that ,s transferred 
bv an RTP packet (for example, encoding system) is 
25 p ovided in the RTP basic header. In tho second em- 
bodiment, for example, if the transferred data » encrypt- 
ed MPEG4 data, this field will be coded with mformation 
indicating "the data is encrypted MPEG4 data- The re- 
cefvingapparatus 102 can knowthat transferred data ,s 
30 encrypted MPEG4 data with reference to this field. 
[0098] Additionally in the second embod.rnent, the 
RTP basic header is provided with an X bit field that in- 
dicates whether or not there is an expansion header 
added to the RTP header. In the second embodiment 
as the arrangement is that a bit indicating "the existence of 
an expansion header" is set. 
r0099] Fig. I2showstheoverallformatof an IP packet 
transferred over the Internet by the second embodi- 

40 roiOOl Fig. 1 3 is a flowchart shows the procedure for 
processing of content distribution in the second embod- 
iment of the present invention. In this second embod.- , 
ment, first the MPEG4 payload header add.ng un. 315 
adds an MPEG4 payload header to the content (step 
45 S400), the step S405 shown in Fig. 4 not being earned 
out The processing of the other steps S401, S403, 
S407 and S409 is similar to the processing as de- 
scribed with regard to the first embodiment. However, 
the header has the above-noted information set into 1 
so [0101] Next,ther e ceivingapparatus102accordingto 
the second embodiment is described below. 
r0102] Fig. 14 shows an example of the configuration 
of the receiving apparatus 102 of the second embodi- 
ment. Similar to the above-noted MPEG4 drtnbutan 
55 server 101, the processing of the MPEG4 expansion 
header is moved to outside of the RTP process^ the 
MPEG4 expansion header receiver/interpreter 705 of 
Fig 8 being moved from inside the RTP processor 703 
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to outside, this becoming the MPEG4 payload header 
receiver/interpreter 715, which is different than in the 
first embodiment. 

[0103] Fig. 15 is a flowchart showing the procedure 
for receiving processing in a receiving apparatus 102 
according to the second embodiment. 
[0104] At the receiving apparatus 102, first a packet 
is received (step S901), and at the RTP basic header 
receiver/interpreter 704 it is learned that the received 
data is encrypted MPEG4 data and that an expansion 
header has been added to the RTP header (step S903). 
Then, at the expansion header receiver/interpreter: 706 
- , it is learned that the expansion header is an encryption 

• expansion header, and possible to learn from the en- 
cryption expansion header the encryption system and 

. whether or not there is updating of the encryption key 
(stepS907). Then, similartothe case of the first embod- 
iment, at the data encryptor/decryptor707the encrypted 
.MPEG4 data is decrypted (step S909), and at the MPEG 
payload header receiver/interpreter 715 the MPEG4 
payload header is interpreted (step S910), and further, 
_ .similar to the first embodiment, at the MPEG4 data gen- 
. erator708, MPEG4 data is. decoded, based on the re- 
. suits of the above interpreting, the results being output- 
ted as an AV output data (for example, an analog signal). 
_ ;> [0105] In /this second embodiment, in. the case in 
... which the payload type field is coded with information 
.that includes notification ;of encryption, the encryption 
r on/pff field of the encryption expansion header need not 
,be referenced, and.in the case in which the payload type 
: field is coded with information thatincludes notification 
■-. /of the encryption, this can be taken as a- notification of 
the possibility of encryption, so that encryption on/off 
, • / field.inithe : encryption.expansion.headercan be usedfor 
r the final determination of whether or not there is encryp- 
v: ."tion:/. : : ... L . . t > y , . . ,\\ ... 

— • Third Embodiment. : ; , « : , ' - r 

: [01 06]:, ".Next, the third embodiment of the. present in- 
vention is described in detail 'below, with reference to 
: • .Fig. 1 6 and Fig. 17. Jn this embodiment, the description 
will focus on differences with respect to the second em- 

• bodiment. ' - •• ., / '-„.;-. V . 

\ , [0107]-., The configuration and processing in the third 
.embodiment are. similar to those : oif the. third embodi- 

- .ment. .? . i . > ■ -.; • . r : . . ? . 

[0108] Fig. 16 shows the formal of the RTP .header 

format used in transmitting encrypted AV data in the 
... third-embodiment, .anchFig. 17 shows the overall IP 
. .packet format transferred via the Internet in the third em- 
». : .bodiment,,. . \ . y . rV ... , — • 

; ; ,[0109] .Specifically, -whereas in. .the second embodi- 
. -ment, in the payload type field within the RTP basic 

header information was coded .that provides notification 
;. of the existence of encryption or the possibility of en- 

cryption, such as "encrypted MPEG4 data",, in the third 
..••embodiment, only n MPEG4° is coded, and information 



including notification of encrypting or the possibility 
thereof is not coded in the payload type field. 
[0110] In the third embodiment, therefore, while the 
receiving apparatus 102 can refer to the payload type 
s field to know that the received data is MPEG4 data, rec- 
ognition with regard to whether or not there is encryption 
is done by referencing the RTP expansion header (the 
encryption expansion header) of the RTP header. 
[0111] In the receiving apparatus 102, at the RTP ba- 
10 sic.header receiver/interpreter 704 it is learned that the 
received data is MPEG4 data, and that an -expansion 
header is' added to the RTP header. Then, at the encryp- 
tion expansion header receiver/interpreter 706, it is 
. learned that the expansion header is an encryption ex- 
15 pansion header, and it is possible to learn from the en- 
cryption expansion header whether or not there is en- 
cryption and whether or not the encryption key. is updat- 
ed. Thereafter, the processing is the same*as in the sec- 
ond embodiment. „..-«•..•; / vL-;*'. 
20 ,..';' . . { ' :. \ r 

- Fourth Embodiment - ,.■ - ; _ ..." ... c< , - , . 

[0112] : Next, the fourth embodiment of the present in- 
: vention is described below with reference to Fig. 18 to 
25,. fig. 23, focusing on the difference between it. and the 
.. second embodiment. - : ... r. . ^ - Te 
. [0113] The difference between.the fourth embodiment 
and the second embodiment is that, whereas in the sec- 

- ond embodimentjhe encryption expansion header is 
30 added to the expansion header of .the RTP header and 

the MPEG4,expansiori_header is.provided as a*payload 
header of the RTP payload (Fig, 11arid ; Fig. 12), jn the 
fourth, embodiment, both the encryption expansion 
headerand the ; MPEG4 expansion header are provided 

as as. a payload .header in the RTP.payload.~(Fig.:,19 and 
. Fig,20). . ... ; - 
[0114] | --.The overall configuration of a network accord- 
ing to the fourth embodiment- is similar. to that of an 
above-noted embodiment (Fig. 1 ), and the processing 

40/ sequence isalso similar to an above T noted embodiment 

v~ ; (Fig. 2). The format of the encryption expansion header 
(encryption payjoad headerin the fourth embodiment) 
is also the same as described above (Fig. 5). V 
[0115] Fig. .18 shows an example of the configuration 

45 of an MPEG4 distribution server # i 01 according to the 
fourth embodimentr In this .embodiment;- because the 
... encryption expansion header added to the MPEG4 ex- 

- ;pansion header is also provided as a payload header in 
. the .RTP payload, the, processing for the encryption ex- 

50 r pansion .header is placed outside the RTP processor, 
and the encryption expansion header adding unit.304 of 
.it.:. Fig. 10 is also moved from within the RTP processor 304 
v to outside, this serving as the encryption payload header 
, • adding unit 314, which is a difference with respect to the 
55 second embodiment 

[0116] Fig. .21 is a flowchart showing the procedure 
for content, distribution processing according to the 
.fourth embodiment .ln the fourth embodiment, in place 
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of step S403 of Fig. 13, an eruption payload header 
°dd no unit 314 adds an encryption payload header to 
The encrypted MPEG4 data (step 403b). The processing 
M other steps S400, S401. S407, and S409 are s.m.lar 

with the exception that the above-noted information is 

roll?? ' if Iws the format of the RTP header 
Sec lin transmission of encrypted AV data in the .fourth 
embodiment. With regard to the payload^ ype flrtdjhe 
fourth embodiment is similar to the second lembodiment 
The function of the X bit field is similar to that .n the sec- 
ond embodiment, and in this embodiment the arrange- 
ment is that a bit indicating "no expansion header (no 
RTP expansion header)" is set. 
FoilS] Fig. 20 shows theoverall format of an IP packet 
ransferred via the Internet in the fourth embodiment. 
01191 Fig 22 shows an example of the configuration 
of a receiving apparatus 1 02 according to the fourth em- 
bodiment. Similar to the case of the above-noted 
MPEG4 distribution server 101, the processing of the 
encryption expansion header is moved to outside the 
RTP processor, and the encryption expansion header 
TeceL /interpreter 706 of Fig. 11 is moved from within 
the RTP processor 703 to outside, this serving as the 
encryption payload header ™™f nte Wf<™ 6 
which is a difference with respecl to the second embod- 

ioSl Fig. 23 shows the procedure for receiving 
proceLing in the receiving apparatus 102 in the ourth 
embodiment. In the receiving *^*' 0 £™* 
packet is received (step S901). and at the RTP ^bawc. 
header receiver/interpreter 704 it is learned i that the re- 
ceived data is encrypted MPEG4 data, and "earned that 
no expansion header is added to the RTP header step 
S903) In this embodiment, subsequent procese.ng is 
prooessingforthe payload. First at the encrypt™ pay- 
toad receiver/interpreter 716 it is learned that the pay 
load is an encryption expansion header, and rt . > also 
possible to learn from the encryption payload Reader 
such information as the encryption system and whethe 
heenoryptionkeyisupdated(stepS907b). Subsequent 

process ng is similar to the case of the second embod- 
iment, the'encrypted MPEG4 date .being I W a 
the data encryptor/decryptor 707 (step S909), he 
MPEG4 payload header being interpreted at the 
MPEG4 payload header receiver/interpreter 715 (step 
S91 0), the MPEG4 data being decoded at the MPEG4 
data generator 708, based on the above interpretation 
results, and the results of this being output as an AV 
output data (for example, an analog signal). 
roS] Similar to the case of the second embodiment, 
n the fourth embodiment in a case in which information 
including notification of encryption iscoded into the pay- 
oad header, it is not necessary to refer to the encryption 
on/off field of the encryption payload header, and if in- 
formation including notrtication of encryption ,s coded in- 
to the payload type field, this can be taken as a notifica- 



tion of the possibility of encryption, so that the encryp- 
Z o of. Md of the encryption payload header can be 
used for the final determination of whether or not Ihere 
is encryption. 

s 

Fifth Embodiment 

[0122] Next, the fifth embodiment of the present in- 
tention is described below, with reference to Fig. 24 
10 through Fig. 26, the description thereof focusing on the 
Sf erence with respect to the second t 
T01231 Fig. 24 shows the format of the RTP header 
used when transmitting encrypted AV data in the fifth 

U embolent. Fig. 25 
is expansion header in the fifth embodiment, and F g. 26 
snows me overall IP packet transferred via the Internet 
in the fifth embodiment. , 
0124] Whereas in the second embodiment informa- 
ion including notification of encrypted data attribu es 
20 °o example' encoding system) such as encrypted 
MPEG4" was coded into the payload type field w, h n 
the RTP basic header (Fig. 11 and Fig. 12) m the f if h 
embodiment only information giving notify -on of he 
fact that the data is encrypted (for example ■encrypted 
2S data") is coded into tho payload type header (Fig. 24 
and Fig 26). While the addition of an encryption expan- 
sion heade as an expansion header to the RTP header, 
and the provision of an MPEG4 expansion header as a 
payload header to the RTP payload are the same as 
so 2 the second embodiment, in the fifth embodiment 
le above-noted encrypted data attributes (encoding 
systemorthe like) are coded into the encryption expan- 
sion header (Fig. 5 and Fig. 25) 
r0125] The overall configuration of the network ac 
3 s cording to the fifth embodiment is similar to that of an 
above noted embodiment (Fig. 1 ), and the sequence of 
processing is also similar to an above-noted embodi- 
ment (Fig 2). The internal configurations of the MPEG4 
Sutton server 101 and the receiving apparatus 102 
40 are alsosimilarto those of the second embodiment (Fig. 

P126] Tshown in Fig. 24, in the fifth embexjiment a 
value ndicating "encrypted data" is codec I into the , pay- 
toad type field of the RTP basic header. The receiving 

terred data is encrypted. In the fifth embodiment, the X 
bit field has a bit that indicates "there is an expans.on 

mm As shown in Fig. 25, in the fifth embodiment, a 
so payload type field is provided in the encryption expan- 
sion header. Information indicating the type o f data 
MPEG4 in this embodiment) in the payload is coded 
ntothopayload type field. Tho receiving apparatus 102 

ss [0128] lnthereceivingapparatus102attheRTPba 
sic header receiver/interpreter 704 it ,s learned that the 
Lerved data is encrypted data, and that there is an ex- 
pansion header added to the RTP header. Then, at the 
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encryption expansion header receiver/interpreter 70£ is 
it learned that this expansion header is an encryption 
expansion header, and from the encryption expansion 
header it is possible to learn such information as the en- 
cryption system, whether or not the encryption key is 
updated, and the type of data in the payload. Similar to 
the case of the second embodiment, the encrypted 
. MPEG4 data is decrypted at the data encryptor/decryp- 
tor707, the MPEG4 payload header is Interpreted at the 
MPEG4 payload header receiver/interpreter 71 5, at the 
MPEG4 data generator the MPEG4 data is decoded 
based on the results of the above interpretation, and the 
results are output as an Ay output data (for example, an 
analog signal). ' ' . 

[0129] In the fifth embodiment, similar to the case of 
the second embodiment, jn the case in which informa- 
, tion including notification of encryption is coded into the 
u , payload type field, ltlsnotnece88a^to>efertDthe.en-- 
. cryption on/off field of the encryption expansion header, 
and if information including notification of encryption is 
coded into the payload type field in the. RTP basichead- 
. er, this'can ,be taken as a notification of the possibility 
; * . of encryption,^ that the encryption on/off field, of the 
■ ^ encryption expansibh, header can be used fonthe final 
Determination of wh other or not'there is encryption . 

_ Sixth Embodiment . ( \ t \ v y„ .Tv^""*' 

•V " [°130] Next the sixth embodiment of the. present in- 
vention is describedbebw with' reference to Fig. 27 and 
Fig. .28, the description focusing pa the difference^ with 
■-■j*'^ respect to the fourth embodiment * "' T 
. . [0131] Fig. 27.shows r "the format of the RTP header 
used 'when;transmitting encrypted AV. data in the sixth 
.. „. embodiment. 4 The encryption expansion header of .this 
\ embodiment is similar tq that shown in Fig,<25, Fig. -28 
~. show's the. overall format of an I P packet transferred via 

thelhternet in the sixth'embodiment/ . ' •• I '^\\ 
Y_ [0132]^" That both the encryption expansion "header 
and tf)e MP EG4, expansion as an 

\. RTPpayload header is similar to the fourth Embodiment 
(Fig! 1 9 and Fig. '20). However, iniContrasUathe fourth 
embodiment, wherein -information including notification 
.."of attributes, of.' encrypted data, such as the/encoding 
system, for example, "encrypted MPEG 4 "-are coded in- 
to the payload type field within the RTf basic header, in 
. .. ,the.sixth embodiment, only information :giving notif lea- 
... lion about thaexistence of encryption (such as "encrypl- 
/ ed data") is coded into the payload type field JFig. 27 
: and Fig. 28). Additionally, while the fact that ahlencryp- 
, tion expansion. header is added as an expansion header 
of the RTP heade^and^n MPEG4 expansion header 
J is added as a payload header to the RTP payload are 
* . the same as in .the second embodiment, in the sixth em- 
bodiment "the above-noted encrypted data attributes (for 
example, encoding system) are coded within 'the en- 
cryption expansion header (Eig. 5 and Fig. 25) . 
_ [0133] The overall .configuration of >the network ac- 



cording to the sixth embodiment is similar to an above- 
noted embodiment (Fig. 1), and the sequence of 
processing is also similar to an above-noted embodi- 
ment (Fig. 2). The internal configuration of the MPEG4 
5 distribution server 101 and the receiving apparatus 1 02 
^ are also similar to those of the fourth embodiment (Fig. 
18 and Fig. 22). ' . . ... 

[0134] As shown in Fig. 27, in the sixth embodiment 
a value indicating "encrypted data" is entered into the 
10 payload type field of the RTP basic header. By referring 
to this field, the receiving apparatus 102 can know that 
the transferred data is encrypted data. The X bit field 
, has a bit that indicates "there is no expansion header". 
. Similar to the case of the fourth embodiment,- informa- 
15 tion indicating the type of data in the payload (MPEG4 
' in this embodiment) is coded into the payload type field 
t . of the encryption expansion header. ■ . ; , t 
[0135] In the receiving apparatus 102, at the RTP ba- 
sic header receiver/interpreter 704 it is.learned that the 
20 received data is encrypted r and it is learned,lhat no ex- 
pansion header, is added to the RTP header... In the sixth 
embodiment, subsequent processing is with respect to 
£ ; , the payload. First, at .the encryption; payload receiver/ 
interpreter 716 .it is learned .that the payload header is 
.25 an encryption expansion ,header, and it impossible to 
, " learn from the encryption payload head such.informa- 
"tion as the encryption "system, whether the encryption 
..key is updated, and type -of data in the payioad. In the 
\^ same manner as in the fourth embodiment, at' the data 
30 - . encryptor/decryptor 707 the encrypted MPEG4 data is 
decrypted' at the, MPEG payload header receive r/inter- 
. preter 715 trie MPEG4 payioad i header is interpreted, at 
the MPEG4 data generator 708 the MPEG4 data is.de- 
. J coded based ori results of. the above interpretation, the 
35^ results being.output as an AV^ output data (for-example, 
v v.an analog signal). _ ; • v -.'. .. " 

r J [0136] In the sixth embodiment, similar to the case of 
the fourth embodiment, in the casein which information 
v , . including notification otencryption is coded into the pay- 
40. /load type field of the RTP basic header,^ it is not neces- 
/., sary to refer to the 'encryption on/off field in the encryp- 
r tion expansion header,, and . if information 'including no- . 
,-r tification jof encryption js coded into the payload type 
.field, this can:be4aken:as a notification of the possibility 
■*f ; of encryption, so that the encryption on/off. field of the 
, encryption expansion, header /can be used for the final 
determination of whether or not there is encryption: 

.. .. Seventh Embodiment ; .. . : . J- ... 

so' '""."' " ; ' " .1'. "" 

: .,[01 37] Whereas in the first- embodiment to the sixth 
.- -embodiment, the present invention was applied to a sys- 
. . tern in which RTP was used as a transport protocol, the 
... present invention can also be applied to systems using 

.other protocols. - * /- 

^ [0138]- In the seventh. embodiment, r instead of using 
RTP as the transport protocol, the distribution of MPEG4 
, T data is ; performed using HTTP (Hyper-Text TransferPro- 
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tocol). that is, a protocol for use between WWW servers 
and Web browsers. 

roi 391 Fig 29 shows an example ol the configuration 
of an information distribution system in the seventh em- 
bodiment. In system shown in Fig. 29, an MPEG4 dis- 
tribution server 6101 according to the seventh embodi- 
ment is connected to the Internet 103, and a reoe.v.ng 
apparatus 6102 according to the seventh embod.ment 
Connected to a LAN 6105, the LAN 6105 being con- 
nectedtothe Internet 103viaaproxy server6104. The 
receiving apparatus 61 02 performs AV stream commu- 
Sion'secU with the MPEG4 distribuL.n server 
6101 via the LAN 6105, the proxy server 6104 and the 
Internet 103. Of course, other MPEG4 distribute serv- 
etandothertypesofequipmentcanalsobeconnected « 

to the internet 103, and other receiving apparatuses and 
other types of equipment can also be connected to the 

mi40] 10 Although in the seventh embodiment, the de- 
sc riplion is that ol the case in which the data type is *> 
MPEQ4, it will be understood, of course, that the present 
invention is not restricted to this type of data. 
r01411 In Fig. 29, the various equipment supports IK 
Ever because of the HTTP proxy server 6104 be- 
tween tho LAN 6105 and the Internet 103, the IP ad- « 
d Te S sontheLAN6105canbeeitheragloballPaddress 

or a private (local) IP address. The term proxy server as 
used herein refers to a server that at one point term - 
nates HTTP (or some other protocol) between the Inter- 
net and an intranet, and functions so as to pin HTTP 
sessions at both ends of the proxy server, and is provid- 
• ed to enable the distribution of HTTP content date re- 
□uested by substantial receiving apparatus (WeD 
browser) to a distribution server (Web server), and tunc- 

servers can be found at, for example, the URL rrttp7/ 
squid.nlanr.net/Squid. In the ^venth embodiment, the 
MPEG4 distribution server 61 01 can be a WWW server, 
andthereceivingapparatus6102canalsobeabrowser 

F01421 Fig. 30 shows an example of the sequence of « 
he authentication process, key exchange process, and 
encrypted data transmission. Because the proxy server 

61 04 is disposed between the receiving apparatus 6 02 
and the MPEG4 distribution server 6101, the actua 
messages (messages transferred as HTTP 'messages) «f 
are in reality relayed via the proxy server 6104, this be- 
ing the onty difference with respect to previously de- 
scribed embodiments (Fig. 2), with other elements of the 
procedure being the same as previously desenbed pro- ^ 

muT With regard to the MPEG4 distribution server 
6101. the receiving apparatus 6102, the packet format, 
if parts of the units in the first through the sixth embod- 
iments dependent upon the transport protocol are mod- 
L to accommodate the HTTP protocol, it . > poss.b.e SB 
to configure an MPEG4 distribution server 6101 a re- 
ceiving apparatus 61 02, and a packet format conform- 
ing to the HTTP protocol. In the following, the example 



is that in which an encryption expansio " ^rte added 
as an expansion header, and in which an MPEG4 ex 
pansion deader is provided as a payload header (as ,n 
the second embodiment). ^.h* 
[0144] Fig. 31 shows the internal configuration of the 
MPEG4 distribution server 6101. 
[0145] As shown in Fig. 31, the MPEG4 .<***« 
Urve 6101 accordingtotheseventh embedment com- 

6302 an MPEG4 payload header adding unit 6305, an 
HTTP processor 6303 that includes an encryption head' 
e Adding unit 6304 and a MIME header add,ng unj 
fi^06 a TCP/IP and UDP/IP processor 6308, a link/ 
pSsical Ser processor 6309, and an authenticate 

SJSn of the sequence shown in Fig. 30 (from 36201 
t0 S6205) and processing related to encryption key up- 
dating is performed by the authentication/key exchange 

M 471 S °tShTTP processor 6303 corresponds to the 
RTP processor in previously described embodiments 
and the MIME (Multipurpose .nternet 
neaderadding unit 6306 corresponds to the RTP basic 
header adding unit in previously described embod,- 

NlS Fig. 32 shows an IP packet that is transferred 
S the internet (and LAN), and Fig. 33 shows deta.te of 
the MIME basic header and encryption expans,on head- 

[0149] in the seventh embodiment, the encryption ex- 
pansion header is transferred as part of the MIME. For 
Z eason, with regard to the encryption expansion 
header, information indicating that this is an encrypt on 
eLansionheader-iscodedintotheContent-Typeofthe 

MIME. The MPEG4 expansion header - transferred as 
part of the Ml ME, along with the encrypted MPEG4 data 
as paytaad header. For the encrypted MPEG4 data to 
which MPEG4 expansion header added, information in-. 
Sng that "this is MPEG4 data' is coded into the 
Se Content-Type. For details with regard to MIME, 
refer to RFC 2045, for example. 
r0150] Theformatoftheencryptionexpansionheader 
s the same as was described for the first embodiment. 
[0151] Fig 34 shows an example of the internal con- 
figuration of the receiving apparatus 6102. 
TO1521 As shown in Fig. 34, the receiv.ng apparatus 
6102 according to the seventh ^ imen j^ p pn ^ 
a link/physical layer processor 6701. a TCP/IP -and 
UDP/IP processor 6702, an HTTP processor 6703 that 
includes a MIME header interpreter 6704 and an en- 
cryption header interpreter 6706, an MPEG payload 
header interpreter 6705, a data encryptor/decryptor 
6707, an MPEG4 data decoder 6708, and an authenti- 
cation/key exchange processor 6711. 
f0153] Processing related to authent.cat.on and en 
cryption in the sequence of Fig. 30 (processing from 
S6201 to S6205) and processing related to encryption 
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key updating is performed by the authentication/key ex- 
change processor 67 11 . 

[0154] The HTTP .processor 6703 corresponds to the 
RTP processor shown in the above-described embodi- 
ments, and the MIME header interpreter 6704 corre- 
sponds to the RTP basic header receiver/interpreter in 
the above-described embodiments. 
[0155] Inthe MPEG4 distribution server 6101, the in- 
putted AV content (for example, an analog signal) is 

, compressed to MPEG4 data by the MPEG4 data gen- 
erator 6301 . Required information is sent as notification 
to the MPEG4 payload header adding unit 6305 from 
the MPEG4 data generator 6301 . , 
— --[0156]— Next-the-MPEG4-data-outputted-from-the- 
MPEG4 data generator 6301 is encrypted by the data 
encrypter 6302. The encryption key used when doing 

, . this is the above-described time-variant encryption key 
Kc. Required information is sent as notification to the 
encryption header adding unit 6304 from the data en- 

... crypter6302. \ 

, [0157] , Next, in the HTTP processor 6303, at the en- 
. : cryption header adding. unit 6304, the encryptionexpan- 
sion header is,added, apd.at the. MIMElheader adding 
unit 6306, a Ml ME 'header is added. V . . 
. [0158] " Encrypted MPEG4 data to which has been 
.. added. a MIME header is sent as a packet shown in-Fig. 
32 to the Internet 6J 03 by .the TCP/I P. and U DP/IP proc- 
essor 6308, via.the link/physical layer processor 6309. 
[0159] In the receiving apparatus 6102, at.the MIME 
. header interpreter.6704, it is. learned that-there is a pos- 
■ . .sibility that the received .data is encrypted, and that an 
. encryption expansion header is added as part of the 
1 . MIME.^At.the.encryption header interpreter 6706 it can 
be learned from the .encryption expansion header 
. whether or hot encryption is present, the encryption sys : 
-,\ Jem and .whether .the encryption key is .updated. In.the 
* ' same manner as in the case of the second embodiment, 
..the data encryptpr/deciyptor 6707 decrypts the encrypt- 
ecJ MPEG4 dataj .at the MREG.4 payload header inter- 
"preting section '6715 the MPEG4 payload header. (sim- . 
..." v ilar to the MPEG4 payload header in previously de- 
.] scribed embodiments) is interpreted, and at the MPEG4 
./data generator 6708 the MPEG4 data is decoded based 
, on the results otthe above interpretation, the result be- 
, t , ing output as an, AVoutput.data (for example, ananalog , 
[ .signal). ~ \ ' * , *' r . ' : ; . , , : ' 0 , 
. [0160] J In the above,, the encryption expansion header 
is added as an expansion header. and the MPEG4 ex- 
pansion header was provided as a payload header oh 
r the payload. However,, it is. also possible to use a differ-; 
. ent configuration, for.exampie one in. which the encryp- 
tion expansion header and MPEG4 expansion header 
. ,.are added as an-expansipn header, or in which the en- 
cryption expansion header and MPEG4 expansion 
header are provided as. a pay load header on the pay- - 
load. . / :?t '_ , , , .. r „ ... . 

[0161] While in.the first to seventh embodiments an 
.Even/Odd field in the encryption expansion header (or 



encryption payload header) was used to notify the re- 
ceiving side from the sending side of updating of the var- 
iable value Nc used for generating the encryption key 
Kc, instead of using the Even/Odd field, it is possible to 
5 send the value of Nc, in which case the Nc value can be 
randomly generated, as opposed to simply being incre- 
mented. The value of Nc can also be changed for each 
individual packet. 

[01 62] While in the first to seventh embodiments RTP 
10 or.HTTP was used as the transfer protocol, it will be un- 
derstood that other protocols can also be used, and fur- 
ther that the network to which the present invention is 
applied is not limited to the Internet. For example, any 

kinds-oMocal area-network r such as Bluetooth, can use 

is the methods of this invention. Further, the present in- 
vention has no restriction in application to the case in 
which the transferred data is MPEG4 data. 
.[0163] Although in the second, third, and fifth embod- 
iments, the data encryptor 302 and data encryptor/de- 
20 icryptor-707 were provided outside the RTP processors 
, .303 and. 307, these can alternately be provided within 
the RTP processors 303 and 307., 

Eighth. Embodiment T *.--,v v . - ..... v 

.- [01 64] , Next, the eighth embodiment of thejp resent in- 
, vention is described below with reference to Fig. 35. 
[0165] Whereas in the first to the seventh'-embodi- 
ments, the description was for the sequencer/shown in 
30 -Fig. 2, it is understood that the present invention cap be 
" applied to other sequences as welt.> "> -.7. 
[0166] The description that follows is for other ;se- 
V quences, for the case in which MPEG4 data distributed 
from. an MPEG4 distribution server is stored; by the re- 
35 ; .ceiying.apparatus. > x . v^.-m;;- ] :-:■-■ 
• [01 67] . The configuration of the jnformatiorh distribu- 
tion system according to.the eighth embodiment is sim- 
ilar to that shown in Fig. ,1. In Fig. 1, an; MPEG4 distri- 
bution server 101 and a receiving apparatus- 102. ac- 
40 . cording to the eighth embodiment are connected -torthe 
.internet 103, MP EG4 AV stream data being secretly 
.. communicated between the MPE.G4;distribution server 
..•--101. and the, receiving -apparatus \102,. via the Internet 
, 103. Of course, other MPEG4 distribution servers and 
45 receiving apparatuses and othertypesof equipment can 
additionally be connected to.the Intern et. 103, t ,/ 
[0168] In the .description of the eighth embodiment, 
while the type of data is MPEG4, it will be understood 
that the eighth embodiment is not-- restricted to applica- 
50, tion to this type.ofrdata, and can be.applied to other data 
types as well. ... . v \ .■}'■. - 

. •;: [01 69] The MPEG4 distribution server .1 0.1 performs 
. distribution of MPEG4 data to the receiving apparatus 
102. MPEG4 data is distributed not in the form of file 
55 transfer, but rather as a stream. When this is done, the 
MPEG4 data that is to be copyright protected is distrib- 
uted J n encrypted form. Before distribution, an authen- 
.* -tication procedure or key exchange procedure is per- 
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formed between the MPEG4 distribution server 101 and 
E^SE — ce used is shown in 

rai71] ' m Fig. 35 shows the sequence ot content layer 
encr ption and authentication, and it should be noted 
that security in layers such as the iP layer and transport 
layer and authentication procedures in those layers 
have been omitted from this drawing, as has the proce- 
dure for assessing charges at the content layer, which 
Ts performed earlier (although there are cases ,n which 
charge assessment and authentication/encryption at 
other layers are not performed). 
r0172l Similar to the case of the first embodiment, the 
MPEG4 distribution server 101 and the receiving appa- 
ratus 1 02 perform authentication and exchange of a cer- 
tificate (equipment certificate) (S7201 , S7202). 
01731 TheMPEG4distributionserver101 mustnotfy 
he receiving apparatus 102 of the encryption , ta» Kc fo 
decrypting the content (AV data that is sent), and the 
2 measure is taken to prevent the unlimitedun- 
authorized copying of the content at the ^appa- 
ratus 1 02 Specifically, when performing storage onto a 
stage medium (for example, a DVD-RAM) of the «- 
coiving apparatus 102, AV data is stored in encrypted 
°Z. VVhen the data stored on the storage medium is 
o be played back, a check is made as to whether the 
data was properly stored on the storage medumand 
not, playback is not possible. That is, if digital copying 
is done from this storage medium onto another storage 
medium (for example, onto another DV-RAM), playback 
is prevented from the copying destination mediura 
r0174] For this reason, notification of the MID, which 
s the ID (serial number) of the storage medium used at 
he receiving apparatus 1 02 is given from the receiving 
apparatus 102 to the MPEG4 distribution server 10 
(step S7203), and atthe MPEG4 distribution server 101 
his MID value is used to encrypt the encrypt™ £ey Kc 
and notify the receiving apparatus 102 (step S7204y 
More specifically, using a pre-established function , B an 
encryption key W is generated of the form W=g(MID), 

tion key Kc (the encryption key Kc encrypted by the en- 

then transmitted. In this arrangement, the value of MID 
is unique to each individual storage medium, and is lo- 
cated in a region of ROM, for example, that cannot be 

ceiving apparatus 102 generates the encryption key W 
in the form W=g(M.D), using the same f unctior i that 
was used at the MPEG4 distribution server 101 , th s en- 
cryption key W being used to decrypt [Kc]w eo as to re- 
cover the encryption key Kc. 

[0176] Thereafter, at the MPEG4 distribution server 
01 MPEG4 data is generated from the AV demand 
MPEG4 data is encrypted using the encryption ke Kc 
shared as described above, the encrypted MPEG4 data 



being then transmitted to the receiving apparatus 102 

K^Uhe receiving apparatus 102, the received 
encrypted MPEG4 data is decrypted using the encryp- 
5 on key Kc determined as noted above and decrypted 
MPEG4 data is decoded, resulting in output of an AV 

roi78] da |n a the eighth embodiment, the receiving appa- 
ratus 02 has a function which, simultaneously with re- 
, 0 eiving the AV data (MPEG4 data encrypted w, h the 
encryption key Kc), or after entering it into a buffer o 
SeBke, stores the received AV data in the form of 
MPEG4 data encrypted using the encryption toy Kc. 
along with the value of [Kc]w, onto a storage medium 
is havinq the above-noted MID. 

miTB] When the above is done, an apparatus tor 
playing back the AV data (MPEG4 data encrypted wrth 
^encryption key Kc)storedon the proper storage-™- 
dium (which can be the receiving apparatus 02, or an- 
20 other equipment) first reads the values o. 

from the storage medium, and then generates the en 
cation key W in the form W=g(MID), this encryption 
key W being used to decrypt [Kc]w so as to recover the 
encryption key Kc. Then the AV data (MPEG4 data en- 
2 s cw tedby the encryption key Kc) stored on the storage 
mTdium is read out and, after decrypting wrt .the en- 
cryption key Kc. the decrypted MPEG4 da a is ^decoded, 
roieoi If AV data (MPEG4 data encrypted by the en- 
cryption key Kc) recorded on a storage medium having 
30 a gLn MID of M1D1 is copied onto a storage medium 
having a MID of MID2, at the equipment that plays back 
the data recorded on the copy destination storage me- 
dium because it is not possible to obtain the original 
S^lttonolpo^lDflene^VJartl^ 
35 notpossibletodeterminelheencryptionkeyKcfromthe 

recorded [Kc]w. As a result, it is not possible to decrypt 
the recorded encrypted data, 
p 81? That is. « proper values of Kc. W and » 

40 out from the copy destination storage medium is M D2 
°he encryption key W generated therefrom is W2=g 
MD2) and if the [Kc]wl read from the storage medium 
"decrypted using W2, a value that is drfferenr born Kb 
results (this being called Kc'). Therefore, an attempt to 
45 decrypt data [DatalKc encrypted with Kc using Kc will 
St in generation of Data", which is dKferent from he 
original data Data, making it impossible to recover the 

Steven « the received AV data (MPEG4 
so data encrypted by the encryption key Kc) is copied onto 
a different storage medium, because the value of MID 
of that storage medium is different, it is possible to pre- 
vent p^back of the AV data, thereby enabling preven- 
tion of unauthorized copying. 
55 [0183] IntheeighthembodimenUheRTPheadenen. 
cryption expansion (payload) header and MPEG4 ex- 
oansion (payload) header and the like can have the 
Sormatasdescribed with regard to the first through 



16 



BNSDOCID <EP 1041823A2_L> 



31 



EP 1 041 823 A2 



32 



the seventh embodiments. 

[0184] Although the above-noted description is for the 
case in which MPEG4 was used as the encoding sys- 
tem, it will be understood that the present invention can 
be applied to other encoding systems as well, in which 
case it is merely necessary to modify the constituent el- 
. ements.of each of the embodiments (for example, the 
MPEG4data generator, the MPEG4 expansion header 
adding unit, the MPEG4 data decoder, the MPEG4 ex- 
pansion header receiver/interpreter, and the like), the 
expansion header (MPEG4 expansion header and 
MPEG4 payload header), and the pay load type coding 
to suit the selected type of encoding system. 
. [0185] The distribution server of the described em- 
bodiments, if necessary, can also be made to send con- 
„ tent in unencrypted form. That is, the coding of the en- 
cryption on/off field and payload type field and the like 
v . can be .established as appropriate to the existence or 
-.. non-existence of encryption. The receiving ,side as well 
-•can check for Ihe presence of encryption from, the head-. 
. ^ er of a received.packet, and control decryption process- 
, . ing accordingly. " \ : •.- ( .' - 
.. : „ : [0186] !: ..The transport protocol used in the foregoing 
J embodiments includes at least RTP.or HTTP. 
., [0187] The. present invention can also be embodied 
. .as a method anda.method according tathe present in- 
; , vention can be embodied as an apparatus. Additionally, 
•the'f unctions of the present invention can-be embodied 
as software as well. • 
, [0188], , The present invention embodied as either an 
: apparatus or a method can>be further embodied as a 

.computer-readable storage medium for storage of a pro- . ■ 
r gram to.be executed by a computer, following a proce- 
dure corresponding to .the present invention (or a pro- . 
gram for causing a computer to function as ameans cor T; 
^ r responding to the present invention ora.program for im- 
t> ..plementing the functions of the present invention with a 
; -^computer). That is, a program for the purpose of imple- 
% ,, rnenting .the processing for content distribution and re- 
ceiving according to the present invention can be stored 
. "onto various types of storage media. The storage medi- 
. \ v u rn is then read by the £PU of a computer implemented 
in hardware, and the stored program is then : executed 
. ". -, v . to embody the present invention. The term storage me- 
. - ;dium used herein can be taken as referring to semicon-v 
ductor memory, magnetic disk (floppy disk.or hard disk), 
.^optical disk (CD-ROM or. DVD or the like), and any other 
^ medium thai can be used Jo store : a program.;. Addition- 
ally, the program can be distributed by various commu- 
nications means, such as a network. 
. v [0189] In summary, according to the present invention 
;/ an encryption, expansion headerjs provided in the form 
. , pf a expansion headeror payload ; header in a transport 
protocol such as RTP (Real-time Transport Protocol) or 
^ HTTP (Hyper-text Transfer protocol), and encryption atr 
tribute information with regard to encryption is coded in- 
to this encryption expansion. header (forexample, pres- 
ence of encryption, encryption system, information with 



regard to copying (encryption. mode indicator: EMI), in- 
formation (Even/Odd field) on which to base generation 
. of a content key (common key) and the like), and by do- 
ing so content data is sent securely from the sending 
s • side to the receiving side, and it is possible at the re- 
, ceiving side to decrypt the encrypted content data trans- 
ferred as a payload. 
v , [0190] In RTP in the past, only the type of encoding 
system used with data of the payload was coded in the 
10 payload type field, so that in the case in which the data 
, stored in the payload was encrypted not in at the net- 
work or transporter layer, but rather at the content layer, 
there, was^no method of giving notification of this to the 
. other, side. - 
16 [01 91] On the other hand, with the present invention, 
because coding is provided in the RTP payload type 
• field to the effect that the content is "encrypted data" or 
."encrypted data encoded by- a specific encoding sys- 
t temY.it is.possible to give notification of this to the other 
20 side, thereby enabling sufficientcopy protection in send- 
ing and receiving encrypted content, as described 
r .above. ■■:*?.•.'>;>.•+* . : . - ■ 

; [0192] , According to -the present invention , as de- 
scribed above, it : is possible. to expand the distribution 
2S of digital content, providing copy protection for AV 
CI; streaming thatcovers not only IEEE 1 394, .butalso:net- 

works such as the Internet and LAN... v; ^./»„ 
O [0193] It is to be -.noted that, . besides .those:, already 
- : mentioned above/ many modifications and variations of 
30 the above embodiments may be made without departing 
; from-the noel and advantageous features of the present 
. . ; :;invention.. Accordingly, all such modifications* and vari- 
.. ations are intended to be included within the scope of 
. ^the appended claims.: . V** v 

■t -\ru' ; ;;.r;:. rr ~< u: : X - 

; ^Claims -c </ ;. r -„ r. \- v ,; : ^-!\\: 

1 . A content information distribution apparatus for dis- 
40 ; ; tributingiencrypted content information, via anet- 
:* - , ; , work in,accordanc.e with a prescribed transport pro- 
•l .'^ tocol, to other end. apparatus lin. a. communication 
authenticated by an authentication process includ- 
ing at least one procedure of an authentication pro- 
45 v. . cedure and a.key exchange procedure, comprising: 

..;C : , ; - (a)-afUnit (302) for- encrypting content informa- 
;j; . lion encoded by a;prescribed encoding system; 
:\ ;;(b),aunit (304) for. generating an encryption at- 
50 . o*. - -.tribute header including attribute information 
t - v with regard to the encryption of the content in- 
formation; 

.(c) aunit(306) for.performing transport protocol 
processing required to .transfer the content in- 
55 formation and for generating a basic transport 

•\ * , headeMo be added to the content information 
r r- . to which .the .encryption .attribute header has 
, been added; and . :■ 
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Id) a unit (309) lor sending to the other end ap- 
paratus that is authenticated a packet including 
the basic transport header, the encryption at- 
tribute header, and the encrypted content infor- 
mation, wherein the encryption attribute header 
is set into an expansion transport header with.n 
a packet header of the packet or into a pay toad 
header within a payload to be encrypted of the 
packet. 

2 The apparatus according to claim 1 , wherein the en- 
' cryption attribute header includes at least one of the 

existence or non-existence of encryption of the con- 
tent information and the encryption system of the 
content information. 

3 The apparatus according to claim 1 , wherein the en- 
' cryption attribute header includes a copy attribute 

field having a plurality of bits with regard to the 
number ol copying ol the conlenl information. 

4 The apparatus according to claim 1 , wherein the en- 
cryption attribute header includes a counter field in- 
dicating a change in an encryption key. 

5 The apparatus according to claim 1 , wherein the 
" ur ,it (b) sets the encoding information, wh.ch indi- 
cates the encoding system for the content informa- 
tion into the expansion transport header or into the 
payload header. 

6 The apparatus according to claim 1 , wherein the 
unit (c) further codes into the basic transport header 
at least information indicating that there is a possi- 
bility that the content information is encrypted and 
wherein the unit (b) codes into the expansion head- 
er at least information as to whether or not the con- 
tent information to be transferred is encrypted. 

7 The apparatus according to claim 1 , wherein the 
' unit (b) codes into the expansion header informa- 
tion as to whether or not the content informat.on to 
be transferred is encrypted. 



8. The apparatus according to claim 1, further com- 

PnS,n ^e) a (305) unit for generating a content at- 
tribute header that includes content attribute infor- 
mation with regard to content information, and for 
settingthis content attribute header into the expan- 
sion transport header or into the payload header. 

9 The apparatus according to claim 8, wherein the 
content attribute header is not encrypted. 

10. The apparatus according to clainr M, wherein the 
unit (a) generates the encryption key based on an 
identifier that uniquely identifies a storage medium 



sent from the other end apparatus in a communica- 
tion. 

11 A content information receiving apparatus authen- 
Heated by an authentication process including at 
least one procedure of an authentication procedure 
and a key exchange procedure and which receives 
encrypted content information via a network in ac- 
cordance with a prescribed transport protocol, com- 

prising: 

(aa) a unit (701) for receiving from a sending 
apparatusapacketcontainingabasictransport 

header, an encryption attribute header includ- 
ing attribute information with regard to the en- 
cryption of the content information, and en- 
crypted content information; 
(bb) a unit (703) for referring to the basic trans- 
port header or encryption attribute header and 
20 judging whether or not the content information 

is encrypted or whether there is a poss.bd.ty 
that the content information is encrypted; and 
(cc) a unit (707) that, when a judgment is made 
by the unit (bb) that the content information is 
2B encrypted, decrypts the encrypted content in- 

formation, based on the attribute information 
with regard to encryption included .n the en- 
cryption attribute header. 

30 12 The apparatus according to claim 11, wherein the 
unit(bb),whenthereisa P ossibilrtythat.hecontent 

information is encrypted, referstotheencrypt.cn a - 
tribute header and judges whether or not the con- 
tent information is encrypted. 

13 The apparatus according to claim 11 wherein the 
unit (bb) refers to the basic transport header or to 
the encryption attribute header to make a judgment 
as to the encoding system of the content forma- 
tion. 

14. The apparatus according to claim 11, further com- 

Pr ' Sin ?dd) a unit (709,710),for referring to a received 
basic transport header and, when a prescribed de- 
iay time has elapsed or a preserved number _of 
packets have been discarded, requesting that the 
sending apparatus send a prescribed encryption 
parameter. 

15 A method of distributing encrypted content informa- 
" tion via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a com- 
"unication authenticated by an f^o. 
ss process including at least one procedure of an au- 
thentication procedure and a key exchange proce- 
dure, comprising the steps of: 
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(a) encrypting content information encoded by 
a prescribed encoding system (S401); 

(b) adding an encryption attribute header in- 
cluding attribute information with regard to the 
encryption of the content information to the en- 
crypted content information (S403); 

(c) adding a content attribute header indicating 
attributes of the content information to content 
information to which the encryption attribute 
header has been added (S405); 10 

(d) performing transport protocol processing re- 
quired to transfer the content information, and 
adding a basic transport header to content in- 
formation to which the content attribute header 

has been added (S407); and is /: 

(e) sending a packet including the basic trans- 
port header, the encryption attribute header, 
the content attribute header, and the encrypted 
content information to the other end authenti- 
cated apparatus (S409), ^ 20 , 



wherein the encryption attribute header, is set . <; >: l 
. into either an expansion transport header within a 

packet header of the packet, or into a pay load head- ,- ( »- 

er within an encrypted payload of the packet. . 25 - : 

1 6. A method of distributing encrypted content informa- .r v 

tion, via a network in accordance with a prescribed t - .. 
transport protocol, to other end apparatus in a com- 

. munication authenticated by an authentication 30-, . 

process including at least one procedure of ah au- ,. - :* . * 

thentication procedure and a key exchange proce- , ; , - T . 
dure, comprising the steps of: 

(a').adding a content attribute header indicating 35 18. 
attributes of the content information to the con- : : * • 
tent information to.be transferred (S400); 
(b 1 ) encrypting content information that are en- • 
coded by a prescribed encoding system and to y . 

which the content attribute header has been 40 
added (S401); ■ : , , r . 

(c') adding to the encrypted content information ';„>• 
an encryption attribute header including attribu- \v w ' ,» 
tion information with regard to the encryption of ■.. -"<- : 
the content information (S403); . . -, . 45 : , * 

(d'j performing transport protocol processing , : ; . 
required to transfer the content information, 
and adding a basic transport header to content 
information to which' the encryption attribute 
header has been added (S407); and so v - 

(e r ) sending a packet including the basic trans- - , : _ 
port header, the encryption attribute header, ; , 
the content attribute header, and the encrypted \ < 

content information to the other end authenti- 
cated apparatus (S409), -. ss 

wherein the encryption attribute header is set 
into either an expansion transport header within a 



packet header of the packet, or into a payload head- 
er within a payload to be encrypted of the packet. 

17. A method of receiving encrypted content informa- 
tion, via a network in accordance with a prescribed 
transport protocol, by an authentication process in- 
cluding at least one procedure of an authentication 
procedure and a key exchange procedure, compris- 
ing the steps of: 



(aa) receiving.a packet including a basic trans- 
port header, an encryption attribute header in- 
cluding encryption attribute information with re- 
gard to the encryption of the content, informa- 
tion, and encrypted content information (S901 ); 

. (bb) referring to the basictransport header and 
judging whether or not the content information 
is encrypted or whether or not there is a possi- 
bility that the content information is encrypted . 

.:.(S903); l( . 

• (cc) referring to the encryption. attribute header 
..and extracting encryption attribute information 

with regard to encryption of the, content infor- 

• . mation (S907); * \ v\- 

. (dd) referring to an expansion transport header 

, : within a packet header of. the packet and ex- 
tracting content attribute information with re- 

-.gard to the content information (S905); and 
(ee) in the case.in which a judgment is made at 

,;i (bb) that the content information is encrypted, 
decrypting, the encrypted, content information, 
based on the extracted encryption attribute in- 

• formation (S909)/ • - 



A method of receiving encrypted content informa- 
tion,, viaa network in accordance with a prescribed 
transport protocoi;by an authenticatiomprocess in- 
cluding at least-one procedures an authentication 
procedure and a key^exchange procedure, compris- 
ing the steps of: 

. c (aa') receiving apacket including a basic- trans-' 
V port<header,:an encryption -attribute header in- 
Ifr .eluding encryption attribute information with re- 
jT gard to the encryption of the content 'informa- 

- tion, and encrypted content information (S901 ); 
.:«•• (bb?) referring^ the basic transport header and 

judging whether or not. the content information 
is encrypted or whether or not there is a possi- 
r; bility that the content information is encrypted 
k- .;(S903); :; •* .;,>■ , r,-: 

- (cc') in the case in which a judgment is made 
r . at (bb') that the content information is encrypt- 

, ed, referring to the encryption attribute header 
and extracting encryption attribute information 

: with regard to the encryption :of the content in- 
formation (S907); , 

; (dd 1 ) in .the case Jn^which a judgment is made 
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at (bb') that the content information is encrypt- 
ed decrypting the encrypted content informa- 
tion based on the extracted encryption attribute 
information (S909); and 
(ee 1 ) referring to an expansion transport header 
within a packet header of the packet and ex- 
tracting content attribute information with re- 
gard to the content information (S910). 

1 9 A computer-readable recording medium for record- 
' jng a program to be executed by a computer, the 
program performing distribution of encrypted con- 
tent information, via a network in accordance with 
a prescribed transport protocol, to other end appa- 
ratus in a communication authenticated by an au- 
thentication process including at least one proce- 
dure of an authentication procedure and a key ex- 
change procedure, the program comprising: 

(a) a module (304) for generating an encryption & 
attribute header including attribute information 
with regard to encryption of the content infor- 
mation; 

(b) a module (306) for performing transport pro- 
tocol processing required to transfer the con- 
tent information and for generating a basic 
transport header to be added to the content in- 
formation to which the encryption attribute 
header has been added; and 

(c) a module (309) for sending a packet includ- 
ing the basic transport header, the encryption 
attribute header, and the encrypted content in- 
formation to the other end authenticated appa- 
ratus, 

wherein the encryption attribute header is set 
either into an expansion transport header within a 
packet header of the packet or into a payload head- 
er within a payload to be encrypted of the packet. 

20 A computer-readable recording medium for record- 
' ing a program to be executed by a computer, the 
program performing receiving of encrypted content 
Information, via a network in accordance with a pre- 
scribed transport protocol, by an authentication 
process including at least one procedure of an au- 
thentication procedure and a key exchange proce- 
dure, the program comprising. 

(aa) a module (701) for receiving from a send- 
ing apparatus a packet including a basic trans- 
port header, an encrypt ion attribute header in- 
cluding attribute information with regard to en- 
cryption of the content information, and en- 
crypted content information; 
(bb) a module (703) for referring to the basic 
transport header or the encryption attribute 
header and judging whether or not the content 



30 



40 



45 



SO 



38 



information is encrypted or whether there is a 
possibility that the content information is en- 
crypted; and 

(cc) a module (707) for decrypting the encrypt- 
ed content information based on attribute infor- 
mation with regardto encryption included in the 
encryption attribute header, in the case in which 
a judgment is made by module (bb) that the 
content information is encrypted, 
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